home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16441 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.2 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
  4. Subject: Re: fastest code
  5. Date: 10 Apr 1996 12:39:19 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4kh2p7INNkcq@keats.ugrad.cs.ubc.ca>
  8. References: <316112A2.7D37@public.sta.net.cn> <4kgbmj$j3j@solutions.solon.com> <4kghs7$250@news1.mnsinc.com> <4kgu7g$n9a@solutions.solon.com>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <4kgu7g$n9a@solutions.solon.com>,
  12. Peter Seebach <seebs@solon.com> wrote:
  13.  >In article <4kghs7$250@news1.mnsinc.com>,
  14.  >Szu-Wen Huang <huang@mnsinc.com> wrote:
  15.  >>Peter Seebach (seebs@solutions.solon.com) wrote:
  16.  >>: In article <1996Apr10.110121.6784@friend.kastle.com>,
  17.  >>: Richard Krehbiel <rich@kastle.com> wrote:
  18.  >>: >Oliver Hellwig <hellwig@rahul.net> wrote:
  19.  >>: >>         for (i=0; i<16; i++)
  20.  >>: >>             prom[i] = prom[i+i];
  21.  >
  22.  >>: HUH?  the code as written has a clear effect, which is to shove all of
  23.  >>: the elements of an array over one.  It certainly is an optimizer bug.
  24.  >
  25.  >>: Read the code carefully; the 2nd reference to prom[] uses a different
  26.  >>: index into the array.  This is not a meaningless statement.
  27.  >
  28.  >>*You* read closely.  The second index is "i+i".  ;)  Okay, so it's a
  29.  >>typo, but one who says "read carefully" is expected to.  Cheers.
  30.  >
  31.  >Okay, so the code becomes undefined when i becomes 8.
  32.  
  33. No it actually does not. The prom array is declared to be 32 elements wide (I
  34. checked the code yesterday, the precise name is something like SA_prom), so
  35. prom[16] is well defined, as is prom[30]. The purpose of the code is to
  36. pack together array elements with even indices in an array of 32 elements;
  37. the loop is correct.
  38.  
  39. What happens is that these 32 bytes are read from a hardware register and
  40. buffered. The code that reads them detects if they come in equivalent pairs and
  41. sets a flag called ``wordlength'' accordingly. If they are in pairs, they have
  42. to be squished, and the offending network card has to be sent a message to stop
  43. doing that (according to my primitive understanding of the code).
  44.  
  45. Secondly, volatile is not going to help. prom[] is not an lvalue representing a
  46. memory mapped I/O region, or any storage that can unexpectedly change between
  47. sequence points, but a perfectly ordinary auto variable.
  48.  
  49.  >And does nothing when i is 0.
  50.  >
  51.  >But the intervening few cases would be expected to produce
  52.  >assignments.
  53.  >
  54.  >I still think eliminating the assignments is a bug, and that "volatile"
  55.  >should not have any effect, but I'll grant that it's far
  56.  >from the only problem.
  57.  
  58. Precisely. Volatile should have no effect here. The values of the array are
  59. subsequently depended on by other code, so eliminating the values is incorrect.
  60.  
  61. The compiler would have to be extremely smart to eliminate the ``compression''
  62. loop and then split the subsequent code into two cases based on whether the
  63. loop was or was not supposed to have happened (this depends on a single
  64. variable ``wordlength'' that is set to either 1 or 2).  But the original poster
  65. said that the compiler kept the loop anyway, just eliminated the assignments,
  66. and it's doubtful that Watcom, or any other compiler, would do this sort of
  67. optimization.
  68. -- 
  69.  
  70.